Method of securely storing and retrieving monetary data

ABSTRACT

A method of securely storing and retrieving monetary values, such as electronic checks and electronic coins. In an interactive protocol between an issuer (e.g., a bank terminal) and a recipient (e.g., a smart card) of electronic money, authentication values (A, B, . . .) are produced by the issuer and are stored in an external storage device (e.g., an electronic wallet). At a later stage, the protocol is repeated between the recipient and the storage to securely retrieve the stored authentication values.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the storing and retrieving of monetarydata. More specifically, the present invention relates to the storing ofmonetary data, such as data identifying electronic checks and electroniccoins, in a storage medium, and to the later retrieval of the storeddata by a means for electronic financial transactions, such as a smartcard.

2. Discussion of the Background

Electronic checks and coins necessarily take up a fair amount of memory,as they include a variety of authentication data, such as a signaturefrom a bank (issuer). Since the storage capacity of a smart card isusually limited, the need arises to store data externally while ensuringthat the electronic money that is retrieved from storage can be trusted,i.e., that the data is valid. To accomplish this it is possible toarrange for use of an on-line protocol with the issuer each time data isloaded from storage. This is however time-consuming and often involvescommunications costs.

SUMMARY OF THE INVENTION

It is an object of the present invention to provide a method for safelystoring and retrieving data, such as monetary data, in which theretrieval of data may be executed off-line. It is a further object ofthe present invention to provide a method which is independent of thespecific type of data, such as electronic checks or coins. It is a stillfurther object of the invention to provide a method in which thevalidity of monetary data may be derived from an interactive protocol.

To this end, the present invention provides a method of securely storingand retrieving data, the method comprising (1) a first phase includingan interaction between an issuer and a recipient, in which dataincluding authentication values are stored in the recipient and in astorage, and (2) a second phase including an interaction between thestorage and the recipient, in which data is retrieved from the storageand is verified by the authentication values and at least oneauthentication value stored in the recipient.

By substantially repeating in the second phase the interaction of thefirst phase, a secure protocol may be achieved. The secure protocoleffectively eliminates the possibility of loading incorrect monetarydata, such as used or forged electronic checks, into the recipient.

Preferably, a first authentication value comprises a commitment producedby the issuer. Such a commitment, (e.g., an electronic signature),allows valid electronic money to be used.

Advantageously, in the second phase the storage verifies theauthentication value received from the recipient.

The method of the present invention thus allows the validity of(monetary) data to be derived from an interactive protocol between anissuer and a recipient, but does not require an interaction with theissuer while retrieving stored data.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows schematically an IC card and an electronic wallet forinteracting with the IC card.

FIG. 2 shows schematically a system for electronic payments, as well asthe exchange of data according to a first phase of the method of thepresent invention.

FIG. 3 shows schematically a system for electronic payments, as well asthe exchange of data according to a second phase of the method of thepresent invention.

FIG. 4 shows schematically a first phase of the method according to thepresent invention.

FIG. 5 shows schematically a second phase of the method according to thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An electronic wallet 2 shown in FIG. 1 is a device for interacting withan IC card 1. The wallet has a keyboard 5, a slot 4 for inserting thecard 1, means for communicating with the inserted card via the cardcontacts 3, and means for communicating with an external terminal, suchas a cash register (not shown). Such a terminal may comprise a cardreader and/or an infra-red card interface for communicating with thecard, preferably via the wallet. The terminal may further comprise meansfor establishing an on-line connection with a money issuing institution,such as a bank, and/or a secure module for securely storing monetaryvalues or the like.

The wallet 2 allows a user to interact with the card 1 via a keyboard 5and a display 6. The wallet 2 allows the user to perform electronictransactions e.g. check balances, transfer balances between accounts,authorize payments, and the like. The wallet also provides a storage forstoring electronic checks, coins and the like, and thus acts as astorage extension for the card. The card 1 is provided with anintegrated circuit (IC) arranged under the contacts 3. The integratedcircuit may comprise a processor, a memory and I/O (input/output) means.As the memory size of present day smart cards is limited, a wallet mayadvantageously be used to store for later retrieval payment data whichcannot be stored on the card.

The system shown schematically and by way of example in FIG. 2 comprisesa recipient 10, a storage 20 and an issuer 30. The recipient 10 and thestorage 20 may correspond with the card 1 and the wallet 2 of FIG. 1respectively. The issuer 30, which may be a bank or another monetarydata providing institution, comprises a terminal suitable forinteraction with the storage (wallet) 20.

In the following text, it will be assumed that the issuer (e.g. bankterminal) 30 issues electronic money, such as electronic checks andcoins represented by suitable data, while the recipient (e.g. smartcard) 10 receives the electronic money. The storage (wallet) 20 is usedboth as an intermediary between the issuer 30 and the recipient 10 andas a storage device for electronic money not stored on the card. It willbe understood that the word "money" in this text is meant to comprisevarious representations of monetary and other values, and specificallycomprises electronic checks and coins. In the following, the terms"monetary data" or just "data" will be used to indicate data related to"money", and especially data representing electronic checks and coins.However, the method of the present invention may also be applied toother data, such as confidential data.

In the method of the invention, the issuer 30 and the recipient 10exchange messages as indicated in FIG. 2. In summary, the recipientgenerates an identification value, performs an interactive protocol withthe issuer while storing the relevant data in the storage, and discardsmost of the data while keeping sufficient data to regenerate theidentification value. When retrieving the data, the identification valueis regenerated, the interactive protocol is performed with the storage20 rather than with the issuer 30 as indicated in FIG. 3, and therelevant data are stored in the recipient 10. The identification valueand the initial value (seed) for regenerating the identification valuemay then be discarded. It will be understood that instead of a value forregenerating the identification value, the identification value itselfmay be temporarily stored.

In the following, it will be assumed that the data exchange between theissuer 30 and the recipient 10 takes place via the storage 20, i.e., alldata pass through the storage 20. It will be understood that it is alsopossible for the issuer 30 and the recipient 10 to communicate directlyand to copy the relevant exchanged data to the storage 20.

Reference will now be made to FIG. 4 in conjunction with FIG. 3. It isnoted that in FIGS. 4 and 5 the recipient, storage and issuer aredenoted by R, S and I respectively. In the method as depicted in FIG. 4,the generation of monetary data (such as electronic checks) is initiatedin step 100, for instance by the recipient 10 sending a relevant requestto the issuer 30. In step 101, the issuer (I) generates a commitment Aassociated with one or more groups of monetary data (electronic checksand/or coins). This commitment A may be produced by generating and usinga suitable cryptographic function F₁ operating upon a random value W:A=F₁ (W). An example of a suitable function F₁ is discreteexponentiation modulo p with generator g of the order q, where q dividesp-1 and where p and q are predetermined (prime) numbers: A=F₁ (W)=g^(W)mod p. The random value W may be predetermined or may be produced instep 101 using a random number generator.

The commitment A, by means of which the issuer commits himself to themonetary data, is sent to the recipient (R), in the present example viathe storage (S) which stores the commitment A. The commitment A may be(temporarily) stored in the recipient as well.

In step 102, upon receiving the commitment A, the recipient generates anidentification value C. This is for example a random number, generatedon the basis of a seed X using a second (random) function F₂ : C=F₂ (X).Optionally, the seed X is the result of combining a (fixed) base seed X₀and an index Y. The index Y, which may have a considerably shorterlength than the seed X, may e.g. indicate an entry in a table of seeds.Preferably, the index Y indicates how many times the function F₂ is tobe applied, starting from the base seed X₀, to obtain the desired seedX. For example, if Y is equal to 3, the seed X may be obtained byapplying the (random) function F₂ three times: X=F₂ (F₂ (F₂ (X₀))).

The seed X is stored in the recipient (R). If a base seed X₀ is used,this base seed is preferably permanently stored in the recipient, whilethe index Y may be stored in the recipient (R) or the storage (S).

Instead of storing the seed X or the index Y, it is also possible tostore the value C. In practice, C will comprise more bits than Y andwill thus require more storage space, making the storing of Y moreeconomical.

Preferably, the relevant value (C, X or X₀) is stored in such a way soas to be directly linkable to a value A. That is, the storage maycomprise a plurality of values A (e.g. each corresponding with a check),with a relevant value (C, X or X₀) being stored for each value A.

Subsequent to the computation of the identification value C, therecipient (R) generates a "fingerprint" E of the identification value Cusing a third function F₃ : E=F₃ (C). Preferably, the fingerprint E alsoinvolves the value A: E=F₃ (C,A). The function F₃ may for exampleinvolve subjecting the combination of the identification value C and thecommitment A to a so-called hash function H: E=H(A,C). This fingerprintE, which identifies the identification value C but from which the valueC cannot be derived, is sent to the issuer.

In step 103, the issuer (I) uses the received fingerprint E to produce avalue B using a fourth function F₄ : B=F₄ (E). Such a function involves,for example, multiplying the fingerprint E by a secret key K_(s) moduloq and adding the result to the previously used random value W:B=W+E·K_(s) mod q. The value B thus derived is stored in the storage(S). The value B, which is the authenticating value of monetary data,may optionally be sent to the recipient (R), e.g. for verificationpurposes, but this is not essential.

It should be noted that the above scheme serves to produce data (e.g.checks) to which both the issuer and the recipient have contributed. Thefinal value B is derived by the issuer from the value E, which is inturn derived by the recipient from the value A. As the value A wasproduced by the issuer, the values concerned are mutually linked.

In a first embodiment of the present invention, the value B is notpassed on to the recipient (R) but stored in the storage (S) for laterretrieval. In a second embodiment of the present invention, the value Bis not only stored in the storage (S), but also sent to the recipient(R) for verification purposes. In the second embodiment, an additionalstep 104 (not shown in FIG. 4) is carried out in which additional data Dmay be derived from the values A, B, C and the public key K_(p)associated with the secret key K_(s). These data D, which are associatedwith the value B, provide additional information with respect to themonetary values concerned. The data D may further be verified using thesame values, for example by verifying whether F₅ (A,B,E)=0, whereD=(A,B,E), i.e. the combination of A, B and E (or C). In actualimplementations, it may be verified whether g^(B) =A·K_(P) ^(E) mod p.The seed X, or alternatively the identification value C, is stored bythe recipient (R). Further data, including the data D and the values A,B and C (or E), may now be discarded, as the generation part of themethod is completed.

FIG. 5 shows the reconstruction process carried out by the system ofFIG. 3. The reconstruction process of the method of the presentinvention is initiated by the recipient (R) in step 110. In step 111 thecommitment A is retrieved from the storage (S). If an index Y was usedin step 102 to determine the seed X, this index Y is also retrieved. Itshould be noted that the storage should not contain both Y and X₀, or X,as that would allow the storage to produce monetary data without theinvolvement of the recipient.

In step 112, the identification value C is regenerated on the basis ofthe seed X. The fingerprint E of the identification value C is alsoregenerated, for example by subjecting the combination of theidentification value C and the commitment A to a so-called hashfunction: E=H(A,C). This fingerprint E, which identifies theidentification value C but from which the value C cannot be derived, issent to the storage S.

In step 113, the stored value B is retrieved. Optionally, thefingerprint E can be checked by verifying whether F₅ (A,B,E)=0. Inactual implementations, it may be verified whether g^(B) =A·K_(P) ^(E)mod p. Subsequently, in step 114 the retrieved value B is used toregenerate the data D from A, B, C and the public key K_(p) of theissuer I. The validity of the thus regenerated data D may further beverified using the same values, for example by verifying g^(R) =A·K_(p)^(E) mod p.

In the above method, data (e.g. D) are generated online and regeneratedoff-line. The method thus offers the possibility of regenerating data(D) without the need to involve the issuer. The issuer only "signs" thedata (in a challenge-signed response exchange involving E and B) in thefirst phase. The method uses a controlled replay of the first phase toregenerate data in the second phase, where the recipient verifies thedata. With the aid of the keys K_(s) and K_(p), a further protection ofthe data is achieved.

As the first (generation) phase may be considered to constitute aninterrupted withdrawal of (e.g. monetary) data, which withdrawal issubstantially repeated by the recipient in the second (reconstruction)phase, the recipient is capable of using identical protocols in bothphases. As a result, there is no need for storing in the recipientadditional code (software) for the second phase, thus effectively savingmemory space.

In the above example, an electronic wallet has been shown as an exampleof an external storage device. The invention may also be used with othertypes of storage devices, such as another card or another terminal.

It will be understood by those skilled in the art that the embodimentsdescribed above are given by way of example only and that manymodifications and additions are possible without departing from thescope of the present invention.

We claim:
 1. A method of securely storing and retrieving data, themethod comprising the steps of:(a) generating a commitment (A) in aterminal; (b) sending the commitment (A) from the terminal to anintegrated circuit card and an electronic wallet; (c) storing thecommitment (A) in the electronic wallet; (d) receiving the commitment(A) in the integrated circuit card; (e) generating, in the integratedcircuit card, an identification value (C) and a fingerprint (E) of theidentification value (C) which identifies the identification value (C)but from which the identification value (C) cannot be derived; (f)sending the fingerprint (E) from the integrated circuit card to theterminal; (g) producing, in the terminal, an authenticating value (B)using the received fingerprint (E); (h) storing the authenticating value(B) in the electronic wallet; (i) retrieving, by the integrated circuitcard, the commitment (A) from the electronic wallet; (j) regenerating,in the integrated circuit card, the identification value (C) and thefingerprint (E) of the identification value (C); (k) resending thefingerprint (E) from the integrated circuit card to the electronicwallet; (l) verifying the fingerprint (E) in the electronic wallet; and(m) retrieving, by the integrated circuit card, the authenticating value(B) from the electronic wallet.
 2. The method according to claim 1,wherein the identification value (C) is stored in the integrated circuitcard.
 3. The method according to claim 1, wherein the steps ofgenerating and regenerating comprise generating and regenerating theidentification value from a seed (X) stored in the integrated circuitcard.
 4. The method according to claim 3, further comprising the step ofgenerating the seed (X) by combining a fixed base seed (X₀) and an index(Y), wherein the index (Y) indicates how many times a function is to beapplied to the base seed (X₀).
 5. The method according to claim 4,further comprising the step of discarding the identification value (C)in the integrated circuit card after the step (e) of generating.
 6. Themethod according to claim 3, further comprising the step of discardingthe identification value (C) in the integrated circuit card after thestep (e) of generating.
 7. The method according to claim 1, furthercomprising the step of discarding the commitment (A) and theauthenticating value (B) in the integrated circuit card after the stepof generating.
 8. The method according to claim 1, wherein the step ofgenerating comprises the step of producing the fingerprint (E) bysubjecting both (1) the identification value (C) and (2) the commitment(A) to a function (H).
 9. The method according to claim 1, wherein thestep (g) of producing comprises the step of producing the authenticatingvalue (B) using the fingerprint (E) and a secret key (K_(s)).
 10. Themethod according to claim 1, wherein the steps (i) and (m) of retrievingcomprise retrieving the commitment (A) and the authenticating value (B)to regenerate monetary data (D).
 11. The method according to claim 10,wherein the step (1) of verifying comprises verifying the regeneratedmonetary data (D) using a public key (K_(p)) of the terminal.
 12. Themethod according to claim 1, wherein the step of generating comprisesthe step of producing the fingerprint (E) by subjecting both (1) theidentification value (C) and (2) the commitment (A) to a hash function(H).
 13. The method as claimed in claim 1, wherein the steps (a)-(h) areperformed in a first phase, and wherein steps (i)-(m) are performed in asecond phase.